Fixes the FieldError crash in #3859.

NonlinearSolvePolyAlgorithmCache (RobustMultiNewton, FastShortcutNonlinearPolyalg) keeps u/fu on its active subcache, not at top level, so every raw cache.cache.u-style read in newton.jl threw FieldError the moment a polyalgorithm was used as the NonlinearSolveAlg inner solver. Its reinit! also left force_stop/retcode set after a branch converged once, so a step!-driven loop silently no-oped forever after and reused a stale iterate.

Per review, both problems are fixed at the interface level in NonlinearSolve.jl#1115 (polyalg get_u/get_fu accessors plus the force_stop/retcode reset in reinit!), merged and released as NonlinearSolveBase 2.39.0. This PR is just the consumer side: every polyalg-unsafe inner-cache read in newton.jl — the resize length check, the stale-W rhs rescale from #4028, both compute_step! paths, and the nlstep build_solution — goes through NonlinearSolveBase.get_u/get_fu. No local workaround remains. Top-level fields the polyalg cache genuinely has (retcode, stats, prob, alg) are read as before, and not_terminated only touches force_stop/nsteps/maxiters, which are also top-level. The nlstep build_solution no longer attaches the inner trace (no polyalg accessor exists; the transient solution only feeds nlprobmap). The compat floor is raised to "2.39", and get_u/get_fu are added to the QA non-public-import allowlist alongside not_terminated.

Regression test nsa_polyalg_tests.jl runs TRBDF2 and FBDF with a RobustMultiNewton inner solver and checks both against the analytic solution of a stiff linear system to 1e-4, plus retcodes. Against the registered NonlinearSolveBase (pinned to the 2.39.0 floor): 8/8 new, and unchanged elsewhere — newton_tests 6/6, nsa_jacobian_reuse 17/17, nsa_matrixfree 14/14, nsa_smooth_est 10/10, nsa_sparse 10/10, nsa_stats 24/24, QA 16/16, all identical to master.

The #3859 MWE (Robertson, TRBDF2(nlsolve = NonlinearSolveAlg(RobustMultiNewton(autodiff = AutoForwardDiff()))), reltol=1e-6, abstol=1e-9) throws FieldError on master and returns Success here, with u(1e5) = [0.0178650, 7.2744e-8, 0.9821349] against a default-FBDF reference of [0.0178659, 7.2748e-8, 0.9821340] (5e-5 relative). The active branch is TrustRegion, and the run is step-for-step identical to NonlinearSolveAlg(TrustRegion()).

Scope: this fixes the crash, not every polyalgorithm. FastShortcutNonlinearPolyalg no longer throws, but its leading branches are Jacobian-free quasi-Newton methods, which do not produce a usable stage step under the one-step!-per-outer-iteration driving mode; the integrator reports Unstable/MaxIters rather than a wrong answer. Polyalgorithms combined with a matrix-free W (linsolve = KrylovJL_GMRES()) are still refused at init by NonlinearSolveBase, identically on master, because _nlalg_with_linsolve cannot push a linsolve into a polyalgorithm; the related SciML/NonlinearSolve.jl#1132 is still open. Both are better addressed by the #3817 redesign (drive inner solvers by solve! per stage) than by more glue here.

AI Disclosure

Claude assisted with this work.